Potential problems I came up with a while ago:

• Specifying the continuation parameter (string passed to the continuation function) may become really weird.
• Teuchos expects strings. We could write a conversion function for this.
• The current parameter list is a mess, because it contains the parameters for different classes. We probably want separate parameter lists for each class. And specify them in the same file as the class.
• If we do the above, specifying the parameters in the actual run scripts (examples) may become a mess, because you need to import 4 different parameter classes.

Specifying the continuation parameter (string passed to the continuation function) may become really weird.

You could simply use the same parameter names such as param_name="rayleigh_number" and then use getattr(parameters, param_name) or use a translation table (similar to Teuchos) and add a function to parameters def get_param_by_full_name(self, param_name) or something. There is plenty of options :-)

The current parameter list is a mess, because it contains the parameters for different classes. We probably want separate parameter lists for each class. And specify them in the same file as the class.
If we do the above, specifying the parameters in the actual run scripts (examples) may become a mess, because you need to import 4 different parameter classes.

You can compose a parameters class made up of multiple sub-classes, in the same way that is now already being done with the EigenValueSettings which is one of the attributes of the Parameters class. If you do not want to import multiple subclasses you can do it without:

option 1, create the default parameters and override options:

    # Define the problem
    parameters = Parameters(
        problem_type='Differentially Heated Cavity',
    )
    parameters.eigenvalue_solver.target = 0
    parameters.eigenvalue_solver.tolerance = 1e-9
    parameters.eigenvalue_solver.number_of_eigenvalues = 5

option 2: have it parse a dictionary

    parameter = Parameters.from_dict({
        'problem_type': 'Differentially Heated Cavity',
        'eigenvalu_solver': {
            'target': 0,
            'tolerance': 1e-9,
        },
    })

Oh, another issue I came up with is that external models (not from Discretization.py) also use e.g. Continuation.py and the eigenvalue solver interface. They have a huge range of parameters. See for instance the list here:

https://github.com/nlesc-smcm/pop-iemic-examples/blob/main/iemic.py#L79

We want to keep that use case working as well.

I'm not sure which of the arguments above still apply to the current code, nearly 1.5 years after your discussion.

My impression is that with !42 !43, the main obstacle to parameters (data)classes has been removed. Continuation is unaware of a parameter dict and lets the interface handle parameter updates. (Not sure if this was the intentation of that change?) It seems that iemic also uses classes for their parameters.

Any discretization & interface implementing parameter dictionaries or dataclasses must just implememt get/set_parameter methods, in the latter case with getattr/setattr as @mark-boer suggested.

If the code must be compatible with Python 3.6 (i.e., no dataclasses), I think normal classes are still preferable to dictionaries.

What are your thoughts on this now?

I don't have the design clear here nor the time to dive into it, but in general everything Mark said is right. Classes are self-documenting in that at least you know which parameters there are, and with type annotations and a type checker you can find many issues much more easily. And as Mark also pointed out, Python has plenty introspection to be able to convert between things as needed. (The iemic example linked above actually shows how OMUSE uses a class-based interface, which has getattr behind the scenes to forward those parameter set operations to the underlying native code.)

As for Python 3.6, I'm pretty conservative with what I support, but the Python community tends to limit support for new releases to Python versions still in official support. Since many packages on PyPI have broken metadata, installing anything on a no-longer-supported version gets difficult pretty quickly, which incentivises people to upgrade. So even though e.g. Ubuntu 18.04 has Python 3.6 and has (paid) support until 2028, anyone still running that OS has already installed a newer Python on it by now. The upshot is that as of last week, you can take 3.9 as a minimum for new releases without upsetting anyone.

I see a lot of the issues have already been solved by explicitly listing the parameters in the constructors, instead of accepting an arbitrary dictionary.

If you wish to have an equivalent of dataclasses, that works on Python3.6, you could consider attrs (it's also better than regular dataclasses).

Feel free to close this PR!